Ok I've pushed up a second commit which should amortize the calls to malloc and reuse internal buffers where possible. I didn't register atexit handlers yet, though, but that may not be too too important in the context of wasm.

This is something I'd like to enable by default with rust-lang/rust, so if binary size is a concern I think it would be better to handle this for every program rather than just those that don't opt-in. I'd also imagine that almost all programs would want to opt-in given how prevalent the concept of a current directory is. I feel like though this sort of a consequence of the wasi-libc strategy, which is that if we want to put stuff in wasm rather than WASI APIs that's inevitably going to make modules larger.

Is there a way to do weak linking tricks or something like that to only pull in this extra processing when chdir is used? If chdir is never used then there's really no need for most of this processing since the current directory is always /.

This is something I'd like to enable by default with rust-lang/rust, so if binary size is a concern I think it would be better to handle this for every program rather than just those that don't opt-in. I'd also imagine that almost all programs would want to opt-in given how prevalent the concept of a current directory is. I feel like though this sort of a consequence of the wasi-libc strategy, which is that if we want to put stuff in wasm rather than WASI APIs that's inevitably going to make modules larger.

Is there a way to do weak linking tricks or something like that to only pull in this extra processing when chdir is used? If chdir is never used then there's really no need for most of this processing since the current directory is always /.

I think that might be possible yes. I think you would want to co-locate chdir and find_relpath in the same object file, then have callers of find_relpath reference it as weak symbol (maybe you could just move find_relpath2 so only once place would need to check for the weak sym).

This is something I'd like to enable by default with rust-lang/rust, so if binary size is a concern I think it would be better to handle this for every program rather than just those that don't opt-in. I'd also imagine that almost all programs would want to opt-in given how prevalent the concept of a current directory is. I feel like though this sort of a consequence of the wasi-libc strategy, which is that if we want to put stuff in wasm rather than WASI APIs that's inevitably going to make modules larger.

Perhaps if its very common then it could be opt-out instead, so tiny programs could link with -D_WASI_EMULATED_CWD=0? Although maybe your weak linking idea is preferable?

Ok so I'm having a really hard time wrangling weak symbols to do what I want. Inevitably they never seem to work for me...

First I refactored a bit where I defined a bunch of weak functions in places and then defined a copy of each function in chdir.c. @sunfishcode's sample program still, however, pulled in the symbols from chdir.c. I think the problem was that a reference to the symbols were made (e.g. posix.c depended on something weakly defined in preopens.c), and the linker found a strong version of the symbol in chdir.c and used that instead.

Next I refactored everything so the meat was defined in chdir.c and it was only referenced weakly from posix.c and preopens.c. The linker, however, still pulled in chdir.c since it seemed to see a reference to the weak symbol and attempted to resolve it.

Basically nothing I did was able to actually work. No matter what I did the linker kept pulling in the strong versions defined in chdir.c, even though chdir was not a referenced symbol. I feel like what I want is to place the chdir.o object into an archive, but I want the archive's symbol table to only list chdir for that object, nothing else defined in there. That way the linker, if it searched for symbols, wouldn't find chdir.c-defined-symbols unless chdir was referenced. I don't think this is an easy feature to implement, however.

I looked a bit though and of the 4k increase it looks like 3k is due to realloc. I changed all the realloc calls to free + malloc and the size increase is only 1k at that point.

I'm not really sure how much this is all worth it in these sense of any nontrivial application is almost surely going to have realloc in it already. Do y'all have other ideas for weak symbols though?

The linker, however, still pulled in chdir.c since it seemed to see a reference to the weak symbol and attempted to resolve it.

This part is confusing me. A weak reference to symbol in chdir.o should not cause the linker to pulling chdir.o if chdir.o is part of an archive file.

Are you declaring the function like this within posix.c/preopens.c?

__attribute__((weak)) void foo(void); 

?

To aid debugging you can try -Wl,--trace-symbol=foo or -Wl,--verbose or if you really want to see all the gory details you can do -Wl,-mllvm,-debug-only=lld

Oh.. I see the problem. The confusion is between weak references and weakly defined symbol. They are confusingly quite different and have completely different uses.

In this case you want weak references to strongly (normal) defined functions.

I think of it like this:

• weak reference: I don't pull objects out of archives. (And could be NULL at runtime so check me before calling!)
• weak symbol: I'm ok with another definition of this symbol overriding me.

We really should not have re-used the word weak for these two different concepts.

In preopens.c I've got:

int __wasilibc_find_relpath_alloc(
const char *path,
const char **abs,
char **relative,
size_t *relative_len,
int can_realloc
) __attribute__((weak));

and it's called like:

    if (__wasilibc_find_relpath_alloc)
        return __wasilibc_find_relpath_alloc(path, abs_prefix, relative_path, &relative_path_len, 0); 

and in chdir.c I have the symbol actually defined, but when linking I get:

$ /opt/wasi-sdk/bin/clang foo.c --sysroot ./sysroot -o foo.wasm -Wl,--trace-symbol=__wasilibc_find_relpath_alloc
./sysroot/lib/wasm32-wasi/libc.a: lazy definition of __wasilibc_find_relpath_alloc
./sysroot/lib/wasm32-wasi/libc.a(preopens.o): reference to __wasilibc_find_relpath_alloc
./sysroot/lib/wasm32-wasi/libc.a(chdir.o): definition of __wasilibc_find_relpath_alloc

(I can gist the full patch too if it helps, it's just not 100% finished yet)

Can you try --trace-symbol chdir to see if anyone else is pulling that object in via that symbol?

That just prints out

./sysroot/lib/wasm32-wasi/libc.a: lazy definition of chdir
./sysroot/lib/wasm32-wasi/libc.a(chdir.o): definition of chdir

Ok so poking around a bit more, if I move chdir.o to the end of libc.a, then __wasilibc_find_relpath_alloc is not pulled in unless chdir is used. If chdir.o comes before preopens.o (which it does on my system) then __wasilibc_find_relpath_alloc is pulled in no matter what.

@sbc100 is this perhaps a bug in the wasm-ld?

Certainly sounds very odd. Are there any symbols that those object file both define? Otherwise I can't think of reason why ordering within an archive could/should matter.

I would love to take a look at a repro for this.. do you repro steps you could include here?

Ok I've pushed up a commit which I think does the weak symbol business. The locally of the example program increases from 38686 to 39021, an increase of 335 bytes.

@sbc100 there's some makefile tweaks here, and if those makefile tweaks are removed then this example program increases 4k in size (pulls in __wasilibc_find_relpath_alloc)

wasm-ld fix: https://reviews.llvm.org/D85567

Nice! I've updated comments in the Makefile about the build logic around chdir.c to reference that change.

Sorry for the delay, but should be updated now!